What do these changes do?

This PR introduces a new RPC client namespace configurable and restrict unintended cross-service calls. This is for now only used in the RPC communication between the api-server (client) and the wb-api-server (server)

Motivation

The simcore_service_webserver package is reused across many services (wb-api-server, wb-auth, wg-garbage-collector, wg-listener, …). This package defines an RPC server under a fixed namespace (WEBSERVER_RPC_NAMESPACE). See in the image below RPC server (4) and RPC clients (1,2,3):

Because all services share this namespace, a client can unintentionally reach any of them.

• Example: api-server should only talk to wb-api-server, but may end up reaching webserver or others.

Changes

• Introduced a configurable RPCClient that allows setting the RPC server namespace.
• Adjusted client-service mappings using WEBSERVER_RPC_NAMESPACE in the app settings:
  • api-server → wb-api-server
  • payments & directorv2 → webserver (stills use the old method)
• Disabled the RPC server for services that should not expose it (e.g., wb-auth, wg-garbage-collector, wg-listener).
• Added a new RPCClient implementation under:
  packages/service-library/src/servicelib/rabbitmq/rpc_interfaces/webserver/v1

Next Steps

• This PR is structured as a safe hot-fix for the release branch (minimal disruption).
• A follow-up PR will be required to clean up redundant code: Retire old webserver RPC client and use new everywhere #8448
  • remove non-v1
  • add new client in payments and directorv2
  • remove default webserver namespace

Related issue/s

• Takes over what was started in WIP: 🐛 Fix/web server rpc namespace #7815

How to test

• 🚨 @bisgaard-itis can you pls add here some steps on how you manually tested it? thx

Update from @bisgaard-itis:

I tested this by running the stack locally and checking that I can run functions via the api-server function interface. I.e. the first call to trigger the celery tasks. Then I scaled the wb-api-server to 0 replicas in portainer and checked, that the function interface was completely broken. Then I did the opposite: Scaled the wb-api-server back to 1 and scaled the web-server to 0. With this, the frontend of course was broken and I checked that I could still run functions via the api-server. This proves that the api-server now sends its RPC requests to the wb-api-server and not the webserver.

Dev-ops

• No new env var required since we reused WB_API_WEBSERVER_HOST for WEBSERVER_RPC_NAMESPACE: ${WB_API_WEBSERVER_HOST}